Dynomotion

Group: DynoMotion Message: 8687 From: fouijar Date: 11/17/2013
Subject: KFlop new release, Encoder input
Hi Tom,

If I remember well something like a year ago there was a discussion about a potential update of the the KFlop to WiFi instead of Ethernet. I do like the idea to have both but this isn't the object of my message.

Actually I think the maximal input rate is about 1Mhz and this is fine for most applications using ' low resolution' encoders. But what about the new servomotors generations using 14, 17, 20 bit resolution?
My point is : why not going to a faster input and probably faster data treatment of the servo loop?
This point is important in terms of vibration management.
Actually, my system is at the limit and a better resolution could help me to avoid null hunts by having a 'better error margin', read wider. This is not the only reason but a higher resolution could help me to get a less noisy system.
What's your opinion? Is there someone else looking in that direction for any reason?

Kind regards,

Jerome

PS: Thanks for the new Konnect board!
Group: DynoMotion Message: 8689 From: Tom Kerekes Date: 11/19/2013
Subject: Re: KFlop new release, Encoder input
Hi Jeome,

We were never able to get the WiFi interface working reliably.

Regarding Encoder inputs over 1MHz.  The limitation comes from our FPGA counters having 8-bits of length.  KFLOP accumulates the changes every servo sample to extend the count range to 52 bits (double precision float).  If more than +/- 127 counts change every servo sample the counter wraps.  So the speed theoretically limited to:

127/90us = 1.411 MHz

There is a possible software workaround to increase the speed that you might try if you are interested.  It is possible for KFLOP to realize that a wrap occurred by monitoring the speed history. 

For example if the previous encoder changes were:

+114 +120 +125 -124

Then it is very obvious that the counter wrapped.  It is physically impossible for the encoder to be counting near +1.4MHz one instant and then -1.4Mhz the next (90us later).  Assume for a moment that at a count rate of 1 MHz the axis is moving at 25mm/sec.  The acceleration required to fully reverse in 90us would be:

50mm/sec / 90us = 555 m/s2 or over 50Gs of acceleration

But there is a disadvantage to the technique.  A possible sequence of encoder changes might be:

+114 +120 +125 0 0 0 0

Which would indicate an acceleration up to 1.4MHz and then a constant speed of 1.4MHz causing constant counter wraps.  Changes of 0 can be caused by: No motion, or motion at 1.4MHz, or 2.8MHz.  Valid history should always make it 100% clear what the case is.   However invalid history, say due to noise, may confuse the algorithm to make it think it is changing at completely the wrong speed or direction. 

I've attached an algorithm to increase the encoder count rate if you wish to try it.

Regards
TK


Group: DynoMotion Message: 8693 From: fouijar Date: 11/20/2013
Subject: Re: KFlop new release, Encoder input

Tom,


Thanks for your input on the subject. My actual setup doesn't need to use the wrap around technique because the encoder ppr is low enough to be within the refresh rate. My question was more oriented to a future setup I have in mind and your answer gave me the position I have to adopt.

But, are you still working on a KFlop next gen ?


Thanks for you support.


Jerome



---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Jeome,

We were never able to get the WiFi interface working reliably.

Regarding Encoder inputs over 1MHz.  The limitation comes from our FPGA counters having 8-bits of length.  KFLOP accumulates the changes every servo sample to extend the count range to 52 bits (double precision float).  If more than +/- 127 counts change every servo sample the counter wraps.  So the speed theoretically limited to:

127/90us = 1.411 MHz

There is a possible software workaround to increase the speed that you might try if you are interested.  It is possible for KFLOP to realize that a wrap occurred by monitoring the speed history. 

For example if the previous encoder changes were:

+114 +120 +125 -124

Then it is very obvious that the counter wrapped.  It is physically impossible for the encoder to be counting near +1.4MHz one instant and then -1.4Mhz the next (90us later).  Assume for a moment that at a count rate of 1 MHz the axis is moving at 25mm/sec.  The acceleration required to fully reverse in 90us would be:

50mm/sec / 90us = 555 m/s2 or over 50Gs of acceleration

But there is a disadvantage to the technique.  A possible sequence of encoder changes might be:

+114 +120 +125 0 0 0 0

Which would indicate an acceleration up to 1.4MHz and then a constant speed of 1.4MHz causing constant counter wraps.  Changes of 0 can be caused by: No motion, or motion at 1.4MHz, or 2.8MHz.  Valid history should always make it 100% clear what the case is.   However invalid history, say due to noise, may confuse the algorithm to make it think it is changing at completely the wrong speed or direction. 

I've attached an algorithm to increase the encoder count rate if you wish to try it.

Regards
TK


Group: DynoMotion Message: 8696 From: Tom Kerekes Date: 11/20/2013
Subject: Re: KFlop new release, Encoder input
Hi Jerome,

We don't have any immediate plans to release any new boards in the near future.

Regards
TK